The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Posture validation refers to a process of granting or denying access to a host that is seeking to access a computer network based on the state of the software installed and running on the host. For example, positive posture validation can occur when an access device, such as a router configured as an access server, determines that a computer seeking network access has a particular kind of anti-virus application, personal firewall, host-based intrusion protection applications, etc.
Steps involved in posture validation typically are performed by a network access device that permits or denies network access, and by an authentication server, which is responsible for obtaining and evaluating the security posture credentials from the network client, determining the overall system posture, and providing the appropriate network access policy to the access device based on the system posture. Optionally, a separate posture validation server application can support validation of the security posture credentials for a particular host application.
The authentication server typically also performs user authentication functions that require a client to prove its identity by offering a data credential that is verified in a secure manner by an authentication server. Some such servers also perform network access control and accounting functions and therefore are termed authentication, authorization and accounting (AAA) servers. A commercial example is CiscoSecure Access Control Server, from Cisco Systems, Inc.
Wireless local area networks such as those that use the 802.1x protocol for wireless communications now commonly use some form of user authentication protocol. For example, Extensible Authentication Protocol (EAP), as defined in IETF RFC 2284, may be used. In EAP over LAN authentication, a wireless client device, such as a laptop computer, that is seeking to obtain network access is termed a supplicant. An AAA server provides user authentication services to an access device, typically a router, which intercepts requests of the supplicant; the access device has the role of a client with respect to the AAA server.
Existing methods of client posture validation allow an access device to mediate an EAP conversation between the supplicant and the authentication server to establish whether the supplicant conforms to required security standards. A supplicant that fails posture validation can attempt validation again at any time after user intervention occurs. For example, a user could install and configure anti-virus protection and then attempt posture validation. Further, an AAA server can force a supplicant to perform posture validation again (“re-validation”) after a specified interval of time by delivering a session timeout message to the access device as part of a successful first validation response. Typically, the interval of time is about one day, to prevent an excessive use of AAA server resources, which could occur if numerous supplicants needed to re-validate too often.
All known approaches for re-validation involve individual requests to particular clients or supplicants. For example, RFC 3576 defines a Change of Authorization message, for the RADIUS protocol, which an AAA server may send to cause an access device to change authorization characteristics for a single supplicant. However, in certain scenarios, it is desirable to require a large number of clients to perform re-validation roughly concurrently; RFC 3576 does not describe a mass re-validation mechanism.
For example, assume that a large enterprise network contains 50,000 user machines managed by 100 access devices; an outbreak of a new virus occurs, and network policy changes to require all machines to have a minimum posture that can protect against the new virus. There is presently no mechanism to force a re-validation of all the user machines from a central point. Instead, in current practice, network administrators are required to contact each network access device and use command-line commands to purge user connections or request a re-validation of each user. During the time required to perform this approach, the new virus could cause extensive damage to resources in the network.
In one other known approach, an AAA server can send a “packet of death” (POD) to an access device that effectively instructs the access device to close a specified user session. Closing the session is a serious disadvantage for several reasons. First, user activities such as downloading a file or interacting with an application are interrupted and terminated, presenting a potentially major annoyance to the user. Second, when the POD approach is used for a large number of clients, the POD approach causes all the clients to attempt to re-establish access device sessions, which in turn causes the access device to attempt to re-authenticate all the clients to the AAA server. Consequently, the AAA server can experience an unreasonable short-term processing load. Further, not all access devices support POD.
Based on the foregoing, there is a clear need for an approach for forcing re-validation of a large number of clients or supplicants. It would be useful to have such a mechanism that is compatible with existing protocol infrastructure in general, and compatible with RADIUS and EAP in particular.